Enhancing the security of the Linux operating system, by providing a comprehensive event logging facility

1.   Introduction
2.   SNARE Overview
3.   Installing and Removing SNARE
4.   Setting the Audit Configuration
5.   Audit Event Viewer Functions
6.   Audit Management Functions
7.   Setting the Network Configuration
8.   About Intersect Alliance

Annex A - List of Audited System Calls
Annex B - Kernel Module Description
Annex C - SNARE Configuration File
Annex D - Event Output Format

• The dynamic kernel module (auditmodule.o)
• The user-space audit daemon (auditd)
• The graphical configuration and reporting tool (snare)

objective,clear,Mon Aug  6 19:43:25 2001,The program /usr/bin/gimp has been executed by the user leigh    event,execve(),Mon Aug  6 19:43:25 2001    user,leigh(500),users(500),leigh(500),users(500)    process,1651,sh    path,/usr/bin/gimp    arguments,gimp    return,0

Figure 1: Main Window

3.   Installing, Removing and Running SNARE

 

4.   Setting the Audit Configuration

4.1   The audit configuration is stored as /etc/audit/audit.conf . As of SNARE Version 0.8, the configuration filename or path may not be changed. This file contains all the details required by the audit daemon to successfully execute. Failure to specify a correct configuration file will not "crash" the daemon, but may result in selected events not being able to be read. Note: Manual editing of the audit.conf file is possible, but care should be taken to ensure that it conforms to the required format for the audit daemon. Also, any use of the graphical SNARE tool to modify security objectives or selected events, will result in manual configuration file changes being overwritten. Details on the configuration file format can be viewed in Annex C - SNARE Configuration File.

4.2   The most effective and simplest way to configure the SNARE audit daemon is to use the graphical front end tool. The audit configuration window can be selected from the Setup -> Audit Configuration menu, or directly from the associated toolbar button.

Auditing Control
4.3   The initial audit configuration parameters to consider are:

a.    The reliability of audit reporting required,
b.    The type of reporting, and
c.    The desired location of the log event file.

4.5   Linux uses a system whereby active system tasks all share the system processor(s). Because audit events can potentially be generated by any or all active process, the audit kernel module must 'cache' audit events until the audit daemon "grabs" it's slice of processor time, and can retrieve the data from the cache. In situations where one task uses a significant amount of processor time without releasing the processor to other tasks, or where the audit daemon is only one of MANY tasks active on the system, there is a possibility that the audit daemon will not receive an adequate slice of processor time to retrieve data from the cache before the amount of memory allocated to the cache is used up by the audit events generated by other tasks on the system. If all available cache within the audit module is consumed, and unless the audit-generating processes are "suspended" to allow the audit daemon to "catch up", then audit data could be lost. As such, the integrity of the event collection process can be 100% guaranteed by selecting the "C2 Style" radio button. However, this will impact on system resources, which may result in the system appearing to temporarilly "hang" or run slower. The "C2 Style" configuration 'pauses' audited system calls for all processes except the audit daemon, until the audit daemon has read some data from the cache, and therefore frees some memory. Selecting the "Normal" radio button will not noticeably impact system resources, but there is a potential for some events to be lost. The quantity of lost events will depend significantly on the system load.

4.7   The type of auditing may either be by "raw kernel events" or by "objectives" (user defined filters). Auditing by raw kernel events will result in all selected system calls being written to the log file, without any form of filtering (other than selecting which system calls are to be audited). The system calls to be audited can be selected via the "Kernel" tab in the Audit Configuration window, as shown in Figure 3 below. This method of auditing is more suited to the classic "C2" style of auditing, where all calls are recorded.

4.8   A more refined method of auditing is available by selecting events via the advanced auditing "objectives" capability. Any number of objectives may be specified, and are listed in the "Objectives" tab, within the audit configuration window, as shown in Figure 4.

4.9   Each of the objectives provides a high level of control over which events are selected and reported. Events are selected from a group of high level requirements, and further refined using selected filters.  All events detailed in Annex A - List of Audited System Calls are contained within all the following high level groups:

a.   Open or create a file or directory.
b.   Remove a file or directory.
c.   Start or stop a program execution.
d.   Modify system, file or directory attributes.
e.   Change or user group identity.
f.    Login or Logout (not available in SNARE Version 0.8)

4.11   The following filters can be applied to incoming audit events:

a.    Filter on the event-specific matchable item.
Each event contains a particular piece of information that represents the core data that needs to be communicated. For the "Open or create a file or directory" group, for example, this would be the name of the file and/or directory opened or created. For the "Start or stop program execution" group, this would be the name of the program in question. The event match allows a "partial", "exact" or "regular expression" match term to check against the event-specific matchable item. A "partial " match will look for the sequence of characters specified somewhere within the event-specific matchable item. For example, if the partial match of "pass" is specified for "Open or create a file or directory", then the following example filenames would all match the term:

• /etc/ passwd
• /usr/lib/ passfilt.so
• /home/red/khyber_ pass.txt

A "exact" match will match the specified term exactly. For example, if the term is /etc/passwd, then the file /etc/passwd would match, but the file /etc/passwd.backup will NOT match.

A "regular expression " match matches the supplied extended regular expression against the event-specific matchable item. Regular expressions are an advanced form of specifying filters, and should only be used by those experienced in using them. For example, the term ".*[Pp]ass(word|wd).*" would match the following:

• /etc/passwd
• /tmp/PasswordFile

but would not match:

• /etc/PASSWD

b.    Filter on user.
Any number of users can be selected, and should be entered with commas separating each user. If no users are entered, ALL users are assumed to be audited.
It is intended that a user exception list will be included into a future release, however, as at version 0.8 of SNARE, this functionality is not yet available.

c.   Filter on return value
An audit event will either return a success or failure return code. SNARE allows a user to filter on the return value.

5.2   A summary version of the event is displayed on the main window. For more details on a specific event, the relevant row from the main window can be selected using the mouse. A pop-up window will then display more comprehensive details related to the event. The details are event context dependant; For example, an "execution" event will display the executed program name, whilst a "file open" event will display the path name of the opened file. The event details window is shown in Figure 5. Note that only certain fields are shown, and others are "greyed out". The fields which are displayed depend entirely on the event (system call) that is being displayed. Once an event window is displayed, other events may be displayed by selecting the "prev" and "next" key.

5.3   The fields shown in the event window relate to the parameters of the system call that was audited. The brief interpretation of the individual fields is discussed below:

5.4   In order to view all previous events contained in the log file, the "Reload" menu item can be selected from Activity->Reload Log File, or from the corresponding button from the toolbar. Note that displaying the entire log file may take some time, depending on the size of the file. Alternatively, the main window event list may be cleared from the menu by selecting the item Activity->Clear all Current Events, or from the corresponding button from the toolbar. Note that clearing the main event viewer, DOES NOT clear the log file.

5.5   The main display will alert the user as to whether the events being generated by the audit daemon are being filtered using the defined objectives, or if events are being passed on without any filtering. This wil be shown to the user via the graphic display at the bottom of the main window which will show either "Display Mode: Objective Information" or "Display Mode: Raw Event Log Data". This is shown at the bottom of Figure 1 .

6.   Audit Management Functions

6.1   The audit daemon is a separate standalone component of the SNARE system, as described in the section on SNARE Overview. However, the SNARE graphical tool can be used to control a number of aspects of its operation. Primarily, the audit configuration can be developed and set using the graphical tool, as described in the previous sections. However, two other functions are available to manage the audit daemon.

6.2   The audit daemon can be restarted directly from the menu item Activity->Apply and Restart Audit. This will instruct the audit daemon to re-read the configuration file, clear the buffers and restart. This function is useful when changes to the audit configuration have simply been saved to the configuration file, without being "applied". The user can therefore select when to activate a new configuration by selecting this menu item, or its corresponding button on the toolbar.

6.3   The audit daemon status can be viewed by selecting the View->Audit Status menu item, or its corresponding toolbar button. This will display whether the audit daemon is active, its process ID, the SNARE version (specifically of the version of the dynamic kernel module, but will apply to all SNARE components), and the total number of events processed by the kernel module. Note that the total events reported are those that have been collected by the kernel, before filtering (if any) by the audit daemon.The audit status window is shown in Figure 6 below.
 

Log Rotation
6.4   Depending on the SNARE configuration, the log file may be small or large. In any case, it is normal houskeeping practice that logs either be rotated or archived. Depending on the site requirements, a rotation scheme that keeps old copies of the last (say) 7 days may be sufficient. In this case, it may be sufficient to simply include a CRON or ANACRON job, and use a program such as logrotate to ensure the current log file does not grow to an unmanageable size. Alternatively, you may wish to archive all log files to backup media such as tape or CD-ROM. This may be scheduled using CRON or undertaken manually. In either case, it is important to note that the audit daemon should restarted, so that it opens the new log file for writing the events.

7.   Setting the Network Configuration

7.1   There are two options for passing audit records to a remote host, either via email or via UDP based network packets. The settings for these options are available from the Setup menu on the man window, or their corresponding toolbar. These settings and the corresponding functionality for passing audit records over the network, however, are not yet available in SNARE Version 0.8.

8.   About Intersect Alliance

8.1   InterSect Alliance is a team of leading information technology security specialists in both the "technical" and "policy" areas. In particular, Intersect Alliance are noted leaders in key aspects of IT Security, including host intrusion detection. Our solutions have and continue to be used in the most sensitive areas of Government and business sectors. Intersect Alliance consult and contract to number of agencies in Australia and in Asia Pacific, for both the business and Government sectors.

8.2   The Intersect Alliance business strategy includes demonstrating our committment and expertise in IT security by releasing Open Source products such as SNARE. Intersect Alliance intend to continue releasing tools that enable users, administrators and clients worldwide to achieve a greater level of productivity and effectiveness in the area of IT Security, by simplifying, abstracting and/or solving complex security problems.

8.3   Please visit the Intersect Alliance website for more information.

A.   The SNARE Audit Subsystem - Events Audited

The Linux Kernel has many system calls available at its disposal. However, SNARE Version 0.8 only implements an auditing facility for those calls that are considered to be the most critical and useful from a security perspective. The list of system calls that can be intercepted by SNARE Version 0.8 is shown in the table below.

List of System Calls Implemented in SNARE Version 0.8

System Call	Description
open	open and possibly create a file or device
creat	open and possibly create a file or device
execve	execute program
exit	terminate the current process
mkdir	create a directory
unlink	delete a name and possibly the file it refers to
mknod	create a directory or special or ordinary file
rmdir	delete a directory
chown	change ownership of a file
lchown	change ownership of a file
chown32	change ownership of a file
lchown32	change ownership of a file
chmod	change permissions of a file
symlink	make a new name for a file
link	make a new name for a file
rename	change the name or location of a file
reboot	reboot or enable/disable Ctrl-Alt-Del
truncate	truncate a file to a specified length
chroot	change root directory
setuid	set user identity
setreuid	set real and / or effective user ID
setresuid	set real, effective and saved user ID
setuid32	set user identity
setreuid32	set real and / or effective user ID
setresuid32	set real, effective and saved user ID
setgid	set group identity
setregid	set real and / or effective group ID
setresgid	set real, effective and saved group ID
setgid32	set group identity
setregid32	set real and / or effective group ID
setresgid32	set real, effective and saved group ID
truncate64	truncate a file to a specified length

The module implements a ring (or 'tail chaser') kernel buffer to cache event information prior to being read by an application that reads data from /proc/audit. The size of the buffer is configurable at module-load time to facilitate installation on low-memory-profile devices if required. The features of the module are:

a.   Events with a path of 1024 bytes can be processed. Paths greater than this size are truncated.

b.   128 kilobytes of memory is allocated for the buffer storage as described in the above paragraph. Events will be lost, if the audit daemon cannot keep pace with reading the events. However, selecting the "C2 Style" option in the Audit Configuration will ensure that events are not lost.

c.   The module is instructed by the audit daemon to audit only selected system calls. System calls that are not specifically selected will not be audited.

Instead of the "all=1" option, the following classes can be added. For example, the command insmod  auditmodule.o file_class=1 will ensure the auditmodule records all the events related to file operations related events. The following audit classes are defined.file_class - File-related audit events

a_open
a_creat
a_mkdir
a_unlink
a_mknod
a_rmdir
a_symlink
a_link
a_rename
a_truncate
a_truncate64

a_chown
a_lchown
a_chown32
a_lchown32
a_chmod

a_execve
a_setuid
a_setreuid
a_setresuid
a_setuid32
a_setreuid32
a_setresuid32
a_setgid
a_setregid
a_setresgid
a_setgid32
a_setregid32
a_setresgid32
a_exit

a_reboot
a_chroot

SNARE can be configured in several different ways, namely:

a.   Via the graphical tool (Recommended), or
b.   By setting module options at load time, or
c.   By manually editing the configuration file

A 'Token' is a group of related data, comprising a 'header', and a series of comma separated fields which make up data that relates to the header.

Examples of tokens:

• process,1628,gcc
• return,0
• path,/etc/audit/audit.conf
• arguments,ls -al

objective,clear,Mon Aug  6 19:43:25 2001,The program /usr/bin/gimp has been executed by the user leigh    event,execve(),Mon Aug  6 19:43:25 2001    user,leigh(500),users(500),leigh(500),users(500)    process,1651,sh    path,/usr/bin/gimp    arguments,gimp    return,0

#!/usr/bin/perl
# Usage: cat /var/log/audit/audit.log | ./extract.pl
# Creates an associative array containing the elements of the event record, and prints the data.

while($input=<STDIN>) {
    chomp($input);
    %Record=();
    @tokens=split(/\t/,$input);    # Split the line into TAB delimited tokens.
    foreach $token (@tokens) {
        @elements=split(/,/,$token);    # Pick out the elements within each token.
        $header=$elements[0];
        if($header eq "objective") {
            $Record{$header}{"criticality"} = $elements[1];
            $Record{$header}{"datetime"} = $elements[2];
            $Record{$header}{"description"} = $elements[3];
        } elsif ($header eq "event") {
            $Record{$header}{"eventid"} = $elements[1];
            $Record{$header}{"datetime"} = $elements[2];
        } elsif ($header eq "user") {
            $Record{$header}{"uid"} = $elements[1];    # User ID
            $Record{$header}{"gid"} = $elements[2];    # Group ID
            $Record{$header}{"euid"} = $elements[3];   # Effective User ID
            $Record{$header}{"egid"} = $elements[4];   # Effective Group ID
        } elsif ($header eq "process") {
            $Record{$header}{"pid"} = $elements[1];    # Process ID
            $Record{$header}{"name"} = $elements[2];   # Process Name (max 16 chars)
        } elsif ($header eq "path") {
            $Record{$header}{"path"} = $elements[1];
        } elsif ($header eq "destpath") {
            $Record{$header}{"destpath"} = $elements[1];    # Destination path
        } elsif ($header eq "arguments") {
            $Record{$header}{"args"} = $elements[1];
        } elsif ($header eq "attributes") {
            $Record{$header}{"attrib"} = $elements[1];
        } elsif ($header eq "return") {
            $Record{$header}{"code"} = $elements[1];
        } elsif ($header eq "target") {
            $Record{$header}{"user"} = $elements[1];
        } elsif ($header eq "owner") {
            $Record{$header}{"user"} = $elements[1];
            $Record{$header}{"group"} = $elements[2];
        }
    }
    # We now have the data in an associative array.
    # Roll through the array, and print the data in token groups.
    foreach $header (keys(%Record)) {
        print "Header: $header\n";
        foreach $element (keys(%{$Record{$header}})) {
            print "$element = " . $Record{$header}{$element} . "\n";
        }
    }

    # In addition, if the event is execve, the effective user ID
    # is 'root', but the real user ID is NOT, then display an alert.
    if($Record{"event"}{"eventid"} eq "execve" && $Record{"user"}{"euid"} eq "root" && $Record{"user"}{"uid"} ne "root") {
        print "Danger: SetUID program " . $Record{"arguments"}{"args"} . " has been run by the user " . $Record{"user"}{"uid"} . " .\n";
     }

    print "\n";
}

print "----- Done -----\n";